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INTEGRATED MATERIAL MANAGEMENT MODULE 

FIELD OF THE INVENTION 

The present invention relates generally to the field of manufacturing systems, and more 
particularly to a stand alone unit or module used to facilitate the interface or communication between 
elements in a system for processing articles, such as semiconductor wafers. 

BACKGROUND OF THE INVENTION 

The field of semiconductor wafer manufacturing has seen the development of technologies 
which minimize wafer contamination, thus maximizing yields, through the use of sealed pods or 
containers for transporting wafers to be processed from one processing tool to another and to and 
from storage areas. Access to the wafers within the containers is had through a standard mechanical 
interface (SMIF). For example, see U.S. Patent 4,532,970. Fabricatibn systems using such pods 
have come to be known as SMIF fabs and the containers have come to be known as SMIF pods. 

Hie system for processing wafers in a SMIF fab will typically include a SMIF pod for 
carrying the wafers, a machine or processing tool (having a processing controller - referred to as the 
"host") for processing the wafers, a robot which is connected to the machine tool for receiving the 
pod and for transporting the wafers from within the pod into position on the machine tool for 
processing, and an identification system to permit identification of a pod. The identification system 
will consist of an identifying tag on the pod, such as a bar code or RF transponder, and a reader. The 
type of reader will depend on the type of identifying tag. 
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In a typical existing installation the identification system would be connected to a Cell 
Controller which manages the process tools via a terminal server or similar hardware and then via 
separate connections to the robot at each tool port. In addition, the Cell Controller would be 
separately connected with the process tools and their associated robots. 

This arrangement is complicated since there are numerous tools within a fab and for each tool 
and its associated robot there are various data collection points for monitoring the environment and 
the articles being processed. Therefore a number of different data inputs is required. Currently, a 
separate computer is required to coordinate the collection of these inputs, hi addition, for each of 
the numerous tools in a fib there is the problem of determining where to locate antennae, controllers 
and power supplies required to effect proper communication. Positioning of the antennae and other 
components significantly complicates the design of any fab. 

Further, the use of an additional computer to effect communication requires means of 
interfacing with such computer and integrating with the various tools. 

v.. 

OR.TECTS OF THF. INVENTION 

It is accordingly a principal object of the present invention to overcome the foregoing 
difficulties and disadvantages. 

It is a specific object of the invention to simplify the current connection arrangement, 
discussed above, by providing a single wire interface between a process tool, the identification 
system, and the robot of that tool to the Cell Controller. Accordingly, this invention provides a 
module which includes a reader for reading the identification tag, and a micro circuit to provide a 
connection route between the identification system and the host, and between the host and the robot. 

-2- 
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Another object of the invention is to provide a simplified connection using lower power 

consumption and modular design so that it can be easily installed. 

Other objects, features and advantages of the present invention will be apparent from the 

description hereinafter. 

SUMMARY A NTI BRIEF DESCRIPTION 

In a semiconductor wafer processing system, the identification system could be of the typical 
RF reader and transponder type, or of a bar code type, or of an IR transceiver type. The robot could 
be of a well know structure for receiving the pod of wafers and moving the wafers into position 
where the process tool will have access to the pod for treating the wafers. The host can either be 
integral with the tool or may consist of a computer network for providing control and instruction to 
each of the tools. 

In operation, the RF Reader of the identification system (or in the case of a bar code the 
optical reader, or in case of an IR system, the IR transceiver) would be mounted on or in the robot 
in such a manner as to permit reading the identification tag when the pod is properly placed on a 
receiving port of the robot. The tag will be read upon command of the host upon receipt of a 
message from the robot that a pod has been placed for processing. All messages and commands from 
the host via the present invention are simply passed to the proper recipient without respect to the 
contents of the message or command. The module of this invention does not provide message 
processing, only message routing. Once the host has determined that the pod is in position it will then 
communicate through the module to the robot to instruct the robot to begin its operation on the pod 
allowing the process tool access to the wafers. The module does not communicate directly with the 
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pod or robot, either through the identification system or other means, and does not require any type 
of data storage or processing capability on the pod to facilitate additional process requirements of 
the wafers contained within the pod. 

The present invention thus operates as a distribution system. It is capable of recognizing the 
source of information and routing it to the proper recipient For example, the signal coming from the 
identification system would be routed to the host. Similar signals that may come from the robot to 
indicate that it has received the pod would also be routed to the host, and signals directed to the robot 
from the host to perform certain functions would be routed through the module. 

The present invention uses lower power to effect communication, is faster and less expensive 
than current techniques, and is a stand alone module that can be easily installed in a variety of tabs. 
The use of this invention does not require reconfiguration of robots or tools and it can interface with 
many different existing robots produced by different manufacturers. 

In addition to the foregoing, the present invention can interface with guided vehicles used in 
a fab for transporting wafer containers. 

The foregoing and other features of the present invention are more fully described with 
reference to the following drawings annexed hereto. 

BRIEF DESCR IPTION OF THE DRAWINGS 

Fig. 1 is a hardware diagram of the functional blocks of a circuit card assembly for a 
microcomputer based module according to the present invention; 

Fig. 2 shows the connection of the integrated material management module of the present 
invention with existing hardware components; 

-4- 



WO 99/31713 PCT/IB98/02147 
Fig. 3 shows the communications link for a guided vehicle; 

Fig. 4 is the overall software calling graph of the integrated material management module 

code; 

Fig. 5 shows the message traffic for a robot to host communication scenario; 
Fig. 6 is the state diagram associated with a message from the robot to the host for SECS 
interface; 

Fig. 7 shows how an unknown state is resolved; 

Fig. 8 shows the message traffic for a host to robot scenario; 

Fig. 9 shows the message traffic for a host to the module scenario; 

Fig. 10 is the state diagram associated with a message from the host; 

Fig. 1 1 shows the message traffic for the module to host scenario; 

Fig. 12 is the state diagram associated with a message from the module; and 

Fig. 13 is the state diagram associated with an ASCII interface. 

DESCRIPTIO N OF THE PREFERRED EMBODIMENTS 

With reference to the drawings, the following is a nonrlindting description of various preferred 
embodiments of the invention. 

Fig. 1 shows the functional blocks of a circuit card assembly 20 (or CCA) for a 
microcomputer based Integrated Material Management Module (IMM) 10. Fig. 2 shows that the 
IMM module 10 provides the connection with an existing host-robot-vehicle-identification message 
stream. 
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Because the technology herein is equally suitable for processing products of types different 
than semiconductor wafers, the semiconductor industry is hereinafter discussed for illustrative and 
descriptive purposes, and the term "wafer" is used hereinafter to designate material, or an article, of 
any equally suitable product. With this is mind, several different embodiments of the invention will 
be described. 

Referring to Fig. 1, in different preferred embodiments of the invention, the host 1 1 could be 
a Manufacturing Execution System (MES) such as the "Factory Works" product produced by 
FASTECH, inc. or the host could be an Equipment Set Controller (ESC) possibly based on the Tool 
Object Model (TOM) or the host could be the tool, itself 

In different preferred embodiments of the invention, the robot 12 could also be an elevator 
or a loader. Still, referring to Fig. 1, in different embodiments of the invention, the identification 
system 13 could also be called a reader or a tracker and could be based on a system such as the 
Iridnet Advanced Tracking System sold by Jenoptik Infab, Inc. The delivery vehicle 14 could be a 
person guided Vehicle (PGV) or a Rail Guided Vehicle (RGV) or an Automated Guided Vehicle 

v.. 

(AGV). In yet another embodiment, the delivery vehicle 14 may be absent, replaced with an 
operator's mamral delivery of wafer carriers. 

The EMM circuit card assembly 20 includes the following functional blocks: 



Power Distri faitio", ™pnaffement and control 

The CCA 20 is powered by a single 24vdc source 15. This is then regulated to supply 5vdc 
18 for the logic components (microprocessor 16, memory, etc.); a separate 5vdc supply 17 which is 
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switched at a frequency greater than 200 khz (to avoid harmonic interference) for the barcode and 
radio frequency identification readers, and 15vdc supply 19 for the Infrared Transceiver identificaiton 
reader 21. In addition, the circuit is provided with a reset control device to insure that upon the 
applicakon of power or a device reset that all of the components are properly initialized to insure a 
deterministic state for program initialization. 

Microprocessor and memory 

The high speed microprocessor 16 is provided with a read only memory (ROM) for the 
purpose of initialization, program maintenance, and program loading. In addition to the read only 
memory, random access memory for program storage and operation is provided in a non-volatile 
form, Le. the memory contents are preserved in the absence of power. The design also provides a 
"mode selection" control where upon initialization the program can determine the communications 
protocol of the host system. 

Coinmppjcations 

The design provides electrical <x>nmninications interfaces to the host system 11 and to robotic 
loading devices 12 via industry standard RS232 serial interface '22. AH interfaces to the host 
equipment, loading services, and reader are under program control. 

Communications to the barcode and/or RF reader 13 is via an industry standard RS232 
interface 23. This interface is configurable for data rate and other serial interface 22. All interfaces 
to the host equipment, loading devices, and reader are under program controL 
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Communications to the barcode and/or reader 13 is via an industry standard RS232 interface 
23. This interface is configurable for data rate and other serial interface parameters as required for 
the receiving device. Power for these devices is provided from the power management and 
distribution section, By providing power directly to the devices the proper power requirements can 
be maintained In addition to the barcode and RF readers, communications support for an Infrared 
Transceiver 21 is provided. This device uses a non-standard serial corninunicatioris methodology 
where a single wire 24 is used for both transmit and receive whereas in a standard RS-232 serial 
interface two wires are used - one for transmit and one for receive. In conjunction with this non- 
standard serial communications methodology the power requirements of the Infrared Transceiver are 
met by the power management and distribution design 19. 

Power up/reset: 

Upon an initial power-up condition, a reset via switch SI, or a reset under microprocessor 
control, the microprocessor Reset Control circuit, maintains a reset state for approximately 350 
milliseconds (ms) to allow power, the microprocessor, and external components to stabilize prior to 
initialization. 

Bootstrap/P rogram Load: 

Upon expiration of the reset timer the microprocessor begins program and hardware 
initialization tasks. Hie "bootstrap" program first initializes the microprocessor 16 to local control 
from internal read only memory (ROM) to perform the hardware initialization of the serial port that 
is required for program load. Once the "loaders/loader serial port is initialized the bootstrap program 
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checks the serial port t determine if a Device Transmit Ready (DTR) signal is present. The presence 
of a DTR signal indicates that the user/host intends to download a new or updated Operational 
Program. The absence of a DTR signal indicates that the existing Operational Program is to be 
executed. If the bootstrap program determines that the existing Operational Program is to be 
executed it executes a program code segment to enable the external memory device containing the 
Operational Program and program execution resumes with the Operational Program 

In the event that the bootstrap program detects that a new or updated Operational Program 
is to be loaded, control is passed to the program load routine which will then interface with the users 
terminal device to control the downloading and verification of the new/updated Operational Program 
Upon completion of this process and the removal of the DTR signal and/or the users terminal device 
the microprocessor, under initial program control, will initiate a device reset to allow control to pass 
to newly installed Operational Program 

Mode selection : 

The invention includes a discrete switch that allows selection of different modes of program 
operation by the Operational Program. Upon program tnirialiTation the Operational Program reads 
the microprocessor port mat the mode control switch is attached to. After performing this function 
the Operational Program initializes to the proper mode and normal operation begins: 

The following modes are supported by the design: 

Mode-0 SECs Messaging with RF ID reader 

Mode- 1 SECs Messaging with Barcode ID reader 

Mode-2 SECs Messaging with Infrared ID reader 



-9- 



WO 99/31713 



PCT/IB98/02147 



Mode-4 
M de-5 
Mode-6 



ASCII Messaging with RF ID reader 
ASCII Messaging with Barcode ID reader 
ASCII Messaging with Infrared ID reader 



Modes 3 and 7 are reserved for future use. 

Below is a (1) System Overview; (2) a Hardware Overview; (3) a Software Overview, (4) 
a description of the Communication Control for a SECS Interface; and (S) Communication Control 
for an ASCII Interface. 

In the following description, reference is made to code designations, identified and described 
in the "APPENDIX." The APPENDIX also includes descriptions of S3F1 message processing; the 
RF ID Interface; the ID Port Handlers; the Serial Port Handlers; the Millisecond Inner Handlers; 
the Watchdog Timer Handlers; and the Executive Routine. 

1. System Overview 

With reference to Fig. 2, the integrated MateriallD System consists of an ED system 13, such 
as an RF ED system, and a specialized micro-controller interface that provides the connection with 

V- 

the existing host-robot (11-12) message stream The micro-controller, or Integrated MateriallD 
Module (IMM), may be configured to accommodate either SECS or ASCII messages. The IMM 
10 is positioned between the host 1 1 and the robot or elevator 12: " 

The IMM module 10 passes messages from the host 11 to the robot 12 and back, unless the 
message is a material id message from the host When it receives a material id message, it intercepts 
the message, reads the material id from the ID system 13, and generates an appropriate response. 
Thus, the robot 11, IMM 10, and the ID system 13 together present an integrated material 
identification capability to the host through the single wire connected to IMM 10. 
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2, Hardware Overview 

The Integrated MateriallD System hardware consists of a micro-controller-based IMM board, 
a separate RF ID system, and a power supply. The IMM is mounted in the robot controller card 
cage, and connections are made through the front paneL The RF ID system consists of an integrated 
RF transmitter and antenna, and is mounted on the base plate of the robot, next to the SMIF pod. 
It is connected to the micro-controller by a flexible cable that has an RS-232 interface and 5V power. 
The power simply is separate from both the micro-controller and the RF ID system, and is mounted 
in the robot chassis outside the card cage. Packaging the RF transmitter and antenna in a separate 
module from the micro-controller avoids introducing RF into the existing robot control system, and 
it provides the capability of reusing the RF ID system in other applications. 

The IMM module uses an 8051 compatible Dallas 87C520 microprocessor. The 
microprocessor has two built-in serial ports 25 and 26, 16 Kbytes of one-time-programmable internal 
read only memory (EPROM), and 128 Kbytes of external data memory configured as non-volatile 
memory through the use of Lithium battery backup which affords up to 10 years of program memory 
retention. In addition to the built-in serial ports, two additional serial ports are available to supply 
communications to an Identification System using industry standard RS232 communications (such 
as bar-code or RF readers) 13, a propriety interface to support the Infra-red Transceiver (IRT) 
component 21 of InfiuVs IridNet Tracking System, and two additional ports (14 for the vehicle and 
14a) to support IRDA infra-red serial communications for providing command and control 
communications for semiconductor wafer transport devices such as push carts, rail-guided vehicles, 
and automated guided vehicles in conjunction with and coordinating with future automated overhead 
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transp its systems used for placing semiconductor wafer carriers directly on the semiconductor 
workstations loadport 

The RF ID system uses a Texas Instruments THUS micro-reader (RI-STU-MRDl) and a 45 
micro-Henry wire loop antenna. Tnis reader was chosen for its small size, low power consumption, 
low radiated energy, and low cost. The entire unit is assembled as one external package, and it is 
connected to the micro-controller through an RS-232 interface. The connecting cable supplies 
regulated power (5 V) as well. 

Both the EMM and the RFID system are powered by a 5V linear power supply, separate from 
the robot power supplies. Tins was done to avoid possible interaction between the switching power 
supplies in the robot and the RF circuity, though in production it may prove desirable to use power 
directly from the robot control system. 

3. Software Overview 

The general structure of the IMM code is that of a communication controller state machine 
driven by events from the serial ports and the millisecond timer clock. The ID system is built as a 
layer on one of the serial ports. The finite state communication control may be configured to handle 
either SECS or ASCII messages (though not both at once!). Currently, this configuration is done 
through conditional compilation which controls the initialization code, though in production except 
for initialization takes place at interrupt level; the background task in the executive does nothing A 
hardware watchdog timer runs in the background and will reset the system if it appears to be hung. 
The overall calling graph (who calls whom) is depicted in Fig. 4. 
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In the SECS configuration, communication whh the h stand the rob t is controlled by the 
SECS communication control module 27, a finite state machine that recognizees the ENQ-EOT- 
MSG-ACK sequence of SECS messages. Its primary purpose is to recognize and block S3F1 
(Material Status Request) messages seat by the host, and to keep track of the state of the host-robot 
communication so that the IMM does not attempt to send a reply in the middle of a host-robot 
conversation. Incoming SECS messages are buffered, and if the message is an S3F1, it is processed 
inme S3F1 module 29, which invokes routines from the ID system 13. The ID system starts an RF 
system read, detects completion, and invokes a callback routine in the S3F1 module 29 to generate 
the S3F2 (Material Status Data) response. 

In the ASCII configuration, all message processing takes place in the ASCII communication 
control module 28. This is a small finite state machine that follows the ASCII communication 
protocol documented in the various Infab service manuals. A message arriving from the host is read, 
buffered, and inspected to see whether it is a READED material id message. If it is not, the message 
is sent to the robot Hie module then waits for a reply from the robot, buffers it, and sends it to the 
host If the message from the host is a material id message, a request is made of the ID system to 
start a read. When it completes, the ID system invokes a callback to send a READID reply to the 
host 

The files that compose the system are: 

reg80c320.h 
• exec.h / exec.c 

SECSA/SECS.c 

S3Fl.h/S3Fl.c 

ASCHh/ASCBLc 

E>Sys.h/IDS.ys.c 

IDPorth/IDPort.c 
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msTimer.h / msTimer.c 
• w<Lh / w<Lc 

serialPorts.h / serialPorts. c 

and they are generated from their respective .html files. 

4 rnrnmiinicfltinn Control for SECS Interface 

The communication control module is command center for IMM activity. Its general purpose 
is to pass messages back and forth from the host to the robot and back, intercepting and acting on 
material ID requests. It must recognize a material ID request, so that it can initiate a read from the 
ID system; and it must recognize when the host and robot are engaged in communication, so that it 
does not attempt to send the reply to a material ID request in the middle of their conversation. 

Design Considerations 

Two general approaches to solving this problem were considered. One was to buffer the 
SECS-I message in the IMM and forward it to its final destination only after the entire message had 
arrived and checked At first this appeared to be a simple, straightforward approach, but it introduces 
complicated problems trying to simulate the behavior of the normal host-robot system in failure 
situations. For instance, what if the IMM receives a message from the host, and then discovers that 
the robot is not responding? How can it notify the host? Without the IMM, the host would know 
immediately that the robot was down: the robot would not even respond to the ENQ-EOT line 
negotiation protocol The IMM responded before it even discovered the robot was down, though, 
so the host will be confused. 
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The approach adopted in the IMM, however, is to forward the message a byte at a time, as 
soon as it arrives. This requires almost no buffering at ail, and the host and robot can maintain an 
accurate picture of status of the link, as if there were no IMM at all. Keeping track of the status of 
the communication link, however, is somewhat more complex. We divide message traffic into robot- 
initiated, host-initiated, and IMM-initiated messages, and discuss them below. 

Message from Robot 

Consider the case of a message from the robot for the host Perhaps it is the response to a 
host inquiry, or an event report directed to the host. The message traffic for this scenario is depicted 
in Fig. 5 

MSG is just a shorthand for the stream of bytes that make up the message — each byte of 
the message is still forwarded as soon as it arrives. The boxes along the IMM line show the state of 
the communication controller, which allows it to recognize when the host-robot link is idle. The 
complete state diagram associated with a message from the robot to the host is shown in Fig. 6. 

Note the contention resolution (state ENQ_robot transitioning to ENQJiost upon receiving 
an ENQ from the robot), which occurs if both the host and the robot attempt to initiate a 
conversation at once. Note, also, that all timeouts return the controller to an IDLE state. 

UNKNOWN state 

Fig. 7 introduces the UNKNOWN state, the state the IMM starts in, and the state it returns 
to when it encounters an unexpected sequence of events. When the IMM is in the UNKNOWN state, 
it simply forwards every byte it receives, and tries to re-sync. It does not initiate any message of its 
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wn, lest it interrupt a host-robot conversation in progress. Although in normal message traffic this 
does not occur, if the host or the robot is restarted or a substantial interruption in the link to one of 
them occurs, an unintelligible sequence can result. This transitions the EMM into an UNKNOWN 
state, which is resolved as depicted in Kg. 7. 

One basic starting point the IMM uses to recognize the status of the link is passage of time: 
if neither the host nor the robot have transmitted anything for a T2 period, it is safe to assume there 
is no conversation in progress and that the link is IDLE. The other starting point is the transmission 
of an ENQ. This is the start of a normal negotiation sequence, and the expected response is an EOT. 
If this does not occur (say one end was just re-started, and the other has not stumbled to the fact yet), 
the IMM re-enters the UNKNOWN state. If both the host the robot follow the SECS-I protocol, 
the IMM will eventually transition out of the UNKNOWN state. The use of an UNKNOWN state 
allows the IMM to accommodate the restart of the host or the robot (or the IMM) in a graceful way, 
to eventually recognize the state of the communication link between them, and not to interrupt the 
normal flow of message traffic while it is doing this. 

Message from Host 

Now the consider the case of a message from the host to the robot The message traffic for 
this scenario is shown in Fig. 8. 
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The decision to forward the message a byte at a time, however, introduces a problem: when 
the host sends a material ID request, how can the IMM know not to send it on to the robot, until, it 
has already sent most of h? The solution used in the IMM is to send the message on to the robot, 
as normal, but to change the final byte of the checksum to an incorrect value, see Fig. 9. 

Note again the contention resolution (state ENQ_robot transitions to ENQJiost upon 
receiving an ENQ from the robot), and the fact that all timeouts return to an IDLE state. 

Message from IMM 

Finally, consider how the IMM sends a message ID reply to the host This is a simple SECS-I 
sequence, shown in Fig. 1 1. 

The robot will behave as if the message has been corrupted, send back a NAK, and take no 
further action. The IMM, however, is aware that the message has been received correctly, and 
returns an ACK to the host. Note that if the message is corrupted in any way, say with a bad 
checksum, it will not be recognized by the IMM as a material ID request and it will be passed on 
through to the robot, where it will be treated as any other unrecognized message. This whole 
approach relies on the robot's ability to reject corrupted messages, of course, but since that is a basic 
part of the SECS-I standard, the approach works reliably. 

A state diagram that is associated with both these sequences is shown in Fig. 10. Characters 
arriving from the robot are ignored until the message has been sent and acknowledged Since under 
normal circumstances this only takes a couple of dozen milliseconds (the message is ten characters 
long, and one character takes about a millisecond at 9600 baud), the robot only experiences a slight 
delay, considerably less than the T2 period that it will tolerate. If the host does not respond to the 
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IMM message and a T2 timeout occurs, then the robot will experience a timeout, too, but that would 
probably have occurred if the IMM had been busy sending a message anyhow. The state diagram 
assocaited with this sequence is shown in Fig. 12. 

Note that the IMM will try to re-send the material ID reply if the host fails to acknowledge 
it the first time. The number of retry attempts, however, currently defaults to 0, in agreement with 
the current robot SECS interface definition. In this configuration, all timeouts return the IMM to an 
IDLE state. 

\ ^"^mfcrtiq" Co"*™ 1 for asctt interface 

The module is responsible for the coordination of all communication with the external devices 
— the host, the robot, the ID system — or the ASCII message protocol configuration. It registers 
itself during initialization as the handler for all communication with the robot and host serial ports, 
and it communicates with the ID system through the ID read interface. Like the SECS 
communication control, it implements a finite state machine, but because it reads and buffers an entire 
message at every step and does not deal with it a character at a timer, the state machine is less 
complicated, see Fig. 13. 

After initialization, the module waits to receive a message in the RECEIVTNGJFROM-HOST 
state. ThereceiveHost routine saves the incoming character sequence in a buffer, and upon receiving 
a or it inspects the message and proceeds to the next step. If the message is a normal robot 
command, not a material id message, enters the SENDING TO ROBOT state and starts transmitting 
the message to the robot serial port. When sendRobot has sent the message, it waits for the robot 
to send a reply in the RECEIVTNG_FROM_ROBOT state. When an entire message has been 
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received from the robot, receiveRobot enters the SENDING_TO_HOST state and starts transmitting 
the message on the host serial port. When the message has been sent, sendHost returns to the 
RECEIVINGFROMHOST state and begins the cycle again. 

If the message is a material id request, "READID," the finite state machine enters the 
R£ADING_£D state and initiates a read from the ID system. When the ID system completes the 
read, it signals the ASCII module by invoking the callback routine with the status and data. This 
routine formats a reply message and sends it to the host. 

Notice that a character can arrive from either source, ROBOT or HOST, at any time, and the 
ASCII module must be prepared to deal with unexpected input This is particularly simple, for there 
is exactly one event associated with each state, and one handler for each event. Thus the routines 
just checks to see that the module is in the state for which they are expected to be active, and if they 
are invoked under other circumstances, they simply ignore the input and return. 

There is a safety net built in to the ASCII module to help it avoid getting locked up. 1£, for 
instance, the terminating in a command should get lost or garbled, the module could wait forever for 
a message to complete. This is done by running the watchdog timer in the background, and clearing 
it whenever the module completes a cycle and re-enters the RECEIVING FROM HOST state. 
Since we don't want the watchdog to go off just because a message hasn't arrived for a while, 
though, we also use the millisecond timer facility to periodically run a timeout routine, which clears 
the watchdog if we are just idle with an empty buffer. 
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APPENDIX 



Communication Control for SECS Interface 

The communication control module is command center for IMM activity. Its general purpose is to 
pass messages back and forth from the host to the robot and back, intercepting and acting on material 
ID requests. It must recognize a material ID request, so that it can initiate a read from the ID system; 
and it must recognize when the host and robot are engaged in communication, so that it does not 
attempt to send the reply to a material ID request in the middle of their conversation. 

Implementation 

Given the description of the state machine above, the code is quite simple, if tedious. The complete 
list of states is 

UNKNOWN 

link status not determined; see discu ssion 

IDLE 

determined that no conversation is in progress 
ENCLrobot v - 

received ENQ from host, forwarded to robot, awaiting EOT from robot 
EOTJiost 

received EOT from robot, forwarded to host, awaiting LEN byte from host 
MSG__robot 

received a message character from host, forwarded to robot, awaiting next character in message 
CHECKurobot 

received last checksum character from host, forwarded to robot, awaiting ACK/NAK 
BADCHECKjrobot 

received last checksum character of ID request message from host, sent corrupted checksum to 
robot, awaiting NAK 
ENQJiost 

received ENQ from robot, forwarded to host, awaiting EOT from host 
EOTjobot 

received EOT from host, forwarded to robot, awaiting LEN byte from robot 
MSGJiost 

received a message character from robot, forwarded to host, awaiting next character in message 
CHECK Jiost 

received last checksum character from robot, forwarded to host, awaiting ACK/NAK 
EDENQJiost 

sending message ID reply, sent ENQ to host, awaiting EOT 
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EDMSGJiost 

received EOT, sent message character to host; if message finished, awaiting ACK/NAK 
In general, every state is associated with three procedures: 

• XXX_enter, a procedure that is executed upon entering the state 

• XXX_proc, a procedure to process events while in that state 

• XXX.timeout, a procedure to handle timeouts while in that state 

For example, there is EOT robot enter. EOT robot proc . and EOT robot timeout . There is a table 
of the event processing procedures , indexed by state, which is used by the interrupt service routines to 
deliver events. 

There is only one externally visible service, SECS sendMsgToHosL to send a message to the host 
when the communication channel is free. It is used by the S3F1 processing module to reply to a 
message ID request. It stores away a pointer to the message to be sent and, if the link is currently 
IDLE, invokes IDENO host enter to start sending the message. If the communication link is busy, 
the next time TDI.R pntpr is called, it will check to see if there is a message to be sent and, if so, 
invoke IDENQ_host_enter to start sending it 

Watchdog Timer 

As in the ASCII interface communication controller , there is a safety net built in to the SECS 
communication controller to help it avoid getting locked up. This is done by running the watchdog 
timer in the background, and clearing it whenever the module completes a cycle and re-enters the 
IDLE state. Since we don't want the watchdog to go off just because a message hasn't arrived for a 
while, we also use the millisecond timer facility to periodically run a timeout routine, which clears 
the watchdog if we arc currently IDT .R. - 



SECS.h 

/* 

Communcation controller for SECS interface 
*/ 

#ifndef _SECS_H_ 
#define _SECS_H_ 

extern void SECS init (void) ? 

extern unsigned" char SECS sendMsaToHost ( 
unsigned char length* 
unsigned char *ptr) ; 

fendif /* _SECS_H_ */ 



SECS.c 

•include 'exec.h* 
• include *wd.h* 
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•include "serialPorts .h" 
I include "msTimer.h" 
♦include -S3Fl.h" 

• include "SECS.h - 



Default SECS parameter values, compatible with Ergospeed 3x00 



unsigned char MaxRetry = DEFAULT_JiaxRe try ; 

/* Control character values */ 
•define EOT 0x04 
•define ENQ 0x05 
•define ACK 0x06 
•define NAK 0x15 

/* forward declarations */ 

static void robotReceive (uchar val) ; 

static void hostReceive (uchar val); 

static void watchdog timeout (uchar dum) ; 

static void pas sThr ouch (uchar src, uchar val); 

static void UNKNOWN enter () ; 

static void UNKNOWN proc (uchar src, uchar val); 
static void UNKNOWN timeout (uchar id); 

static void I DLE enter ( ) ; 

static void IDLE proc (uchar src, uchar val); 
static void ENQ robot enter (); 

static void ENQ robot proc (uchar src, uchar val); 
static void ENQ robot timeout (uchar id) ; 

static void EOT host, enter ( ) ; 

static void EOT host proc (uchar src, uchar val); 
static void EOT host timeout (uchar id) ; 

static void MSG robot enter (uchar len) ; 

static void MSG robot proc (uchar src, uchar val); 

static void MSG robot timeout (uchar id) ; 

static void CHECK robot enter M; 

static void CHECK robot proc (uchar src, uchar val) ; 
static void CHECK robot timeout (uchar id); 

static void BADCHECK robot enter 

static void BADCHECK robot proc (uchar src, uchar val); 
static void BADCHECK robot timeout (uchar id); 

static void ENQ host enter () ; 

static void ENQ host proc (uchar src, uchar val) ; 
static void EN Q host timeout (uchar id); 

static void EOT _r obot_enter ( ) ; 

static void EOT robo t proc (uchar src, uchar val); 
static void EOT robot ti meout (uchar id); 



*/ 

•define DEFAULT_Tl_ms 
•define DEFAULT_T2 _jns 
•define DEFAULT_MaxRe try 



500 
10000 
0 



unsigned short Tl_ms 
unsigned short T2_ms 



= DEFAULT_Tl_ms ; 
= DEFAULT_T2_ms ; 
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static void MSG ho st e nter (uchar len) ; 

static void M SG_host proc (uchar src, uchar val) ; 

static vo i d Msg h pst timeout ( uchar id ) ; 

static void CHE CK host enter ( ) ; 

static void CHECK host proc (uchar src, uchar val); 
static void CHECK host timeout (uchar id); 

static void IDENO host enter (); 

static void IDENO host proc (uchar src, uchar val) ; 
static void IDENO_host timeout (uchar id); 

static void IDMSG host enter (); 

static void IDMSG host proc (uchar src, uchar val); 
static void IDMSG host timeout (uchar id) ; 

static void SECSMSG init (void); 

static void SECSMSG proc (uchar inChar, uchar remain, uchar *abortFlag) ; 
static void SECSMSG ack (void) ; 

/* Globals V 

/* States */ 

enum 

( 

UNKNOWN = 0, 
IDLE, 

ENQ_robot , /* host- robot sequence */ 

E0T_host, 

MSG_robot, 

CHECK_robot , 

BADCHECK_robot, /* end host-IMM sequence */ 
ENQ_host, /* robot -host sequence */ 

E0T_robot , % 
MSG_host, 
CHECK_host, 

IDENQ_host, /* IMM-host sequence */ 

IDMSG_host, 

MAX_STATE /* sentinel */ 

)? 

/* Branch table — handler for each state */ 

typede f void ( *handl er Proc ) ( uchar , uchar ) ; 

code handler Proc handler (] = 
( 

UNKNOWN_proc , 
IDLE_proc , 
ENQ__robo t_proc , 
E0T__hos t^proc , 
MSG_robb tjroc , 
CHECK_robo t_proc , 
BADCHECK w robot_proc , 
ENQ_hos t_proc , 
E0T_robo t_proc . 
MSG_hos t_proc , 
CHECK_hos t_proc , 
IDENQ_host_proc , 
IDMSG_hos t_proc 

); 

static uchar state = UNKNOWN; 
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•define BUF_SIZE 256 

static xdata uchar buf (BUF_SIZE| ; 

static uchar buf Index; 

static uchar charRemain; 

static uchar timerlD; 

static uchar rasgLen; 

static uchar *rasgPtr; 

static uchar tryCount ; 

void 

SECS_init (void) 
( 

msgPtr = NULL; 

SER setHandler (ROBOT. RECEIVE, robotReceive ) ; 
SER setHandler (HOST, RECEIVE, hostReceive ) ; 

UNKNOWN enter () ; 

watchdog timeout ( 0 ) ; 

) 

static void 

robotReceive (uchar val) 
( 

( handler ( s ta t e ] ) ( ROBOT , val ) ; 

) 

static void 
hostReceive (uchar val) 
( 

(handler{state) ) (HOST, val) ; 

) 

bool 

SECS_sendMsgToHost (uchar length, uchar *ptr) 
( 

if (msgPtr ! = NULL) 
return FALSE; 

rasgLen = length; 
msgPtr = ptr; 
tryCount = 0; 

if (state == IDLE) 

IDENO host enter (); 

return TRUE; 

} 

static void 

watchdog_tiiaeout (uchar dum) 
{ 

if (state =» IDLE) 
WD reset ( ) ; 

MST create (10000. watchdog_ timeout) ; 

) 

static void 

passThrough (uchar src, uchar val) 
( 

if (src ROBOT) 

SER put (HOST, val); 
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else if (sre « HOST) 

SER put f ROBOT, val) ; 

) 

static void 
UNKNOWN_enter ( ) 
{ 

state = UNKNOWN; 

timer ID = MST create (T2_ms . UNKN OWN _t i meouc ) 

) 

static void 

UNKNOWNLproc (uchar sre, uchar.„val) 
{ 

passThrouoh (sre , val); 
MST cancel (timer ID) ; 

if (val » ENQ) 
( 

if <src == HOST) 

ENQ robot enter () ; 
else if (sre == ROBOT) 

ENQ host enter O ; 

) 

else 

UNKNOWN enter () ; 

} 

static void 

UNKNOWN„timeout (uchar id) 
( 

if (timer ID == id) 
IDLE_enter ( ) ; 

> 

static void 
IDLE_enter ( ) 
{ 

WD reset i) : 

if (msgPtr ! = NULL) 

yPENQ host er^t;er(); 

else 

state = IDLE; 

) 

static void 

IDL£_proc (uchar sre, uchar val) 
{ 

passThroual> (sre , val) ; 

if (val == ENQ) 
( 

if (sre == HOST) 

ENQ robot enter O; 
else if (sre == ROBOT) 

ENQ host enter () ; 

) 

else 

UNKNOWN enter O ; 

> 

static void 
ENQ_robot_enter ( ) 
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{ 

state = ENQ_robot ; 

timerlD = MST create (T2_ms . ENO _robot_timeout) ; 

) 

static void 

ENQ_robot__proc (uchar src, uchar val) 
( 

p assThrouah ( src , val ) ; 

if (src == ROBOT) 
( 

if (val =- EOT) 
{ 

MST cancel (timer ID) ; 
EOT host enter O ; 

) 

else if (val =** ENQ) 
{ 

MST cancel ( timer ID) ; 
ENO host enter () ; 

> 

else 

/* wait for another character from robot 

) 

else 
< 

MST cancel (timer ID) ; 
UNKNOWN enter M ; 

) 

) 

static void 

ENQ_r obo t_t imeou t (uchar id) 
( 

if (timer ID == id) 
IDLE enter <) ; 

) 

static void 
EOT_host_enter ( ) 
{ 

state = EOT_host; 

timer ID = MST create (T2_ms . EOT host timeout ) ; 

) 

static void 

EOT_host_proc (uchar src. uchar val) 
( 

passThrouah ( src . val); 
MST cancel ( timer ID) ; 

if (src == HOST && 10 <= val val <= 254) 
MSG robot enter (val) ; 

else 

UNKNOWN enter () ; 

) 

static void 

EOT_hos t_t imeou t (uchar id) 
{ 

if (timer ID «» id) 
IDLE e n ter ( ) ; 



-26- 



WO 99/31713 



PCT/IB98/02147 



Communcation controller for SECS interface 



J 

static void 

MSG_robot„enter (uchar len) 
( 

state = MSG_robot; 

charRemain = len + 2; /* include checksum */ 
timerlD = MST create (Tl_ms , MSG robot timeout ) : 

SECSMSG in it ( ) : /* start saving message for SECS processing */ 

) 

static void 

MSG_robot_proc (uchar sre, uchar val) 
( 

uchar abortFlag; 

MST cancel ( timer ID) ; 

if (sre == HOST) 
( 

— charRemain ; 

SECSMSG proc (val, charRemain, iabortFlag) ; /* store, process SECS message 

if (charRemain == 0) 

( 

if (abortFlag) 
{ 

5gn pu,t; (ROBOT, ~val); 
BADCHECK robot enter f): 

} 

- } else 

< , 
SER put (ROBOT, val); 
CHECK robot enter f); 

) 

> 

else 
( 

SER_put (ROBOT, val); 

timer ID = MST create (Tl_ms, MSG robot, timeout ) ; 

) 

> 

else 
{ 

SER put (HOST, val); 
UNKNOWN enter M: 

) 

) 

static void 

MSG_robo t_t imeout ( uchar id ) 
{ 

if (timerlD == id) 
IDLE enter ( ) ; 

) 

static void 
CHECK_robot_enter ( ) 
( 

state = CHECK_robot; 

timerlD = MST create (T2_ms , CHECK__robot_ timeout) ; 

) 
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static void 

CHECK_robot_proc (uchar src, uchar val) 
{ 

pas sThrouqh (src. val) ; 
MST cancel ( timer ID) ; 

if (src == ROBOT && (val == ACK || val NAK) ) 
( 

if (val == ACK) 

SECSMSG ack ( ) ; /* indicate ACK to SECS message processing */ 
IDL£ _enter ( ) ; 

) 

else 

UN KNOWN enter () ; 

) 

static void 

CHECK_robot_tiraeout (uchar id) 
( 

if (timerlD == id) 
IDLE__ente r ( ) ; 

) 

static void 
BADCHECK_robot_enter ( ) 
( 

state = BADCHECK_robot ; 

timer ID = MST create (T2„ms . BADCHECK_robot_ timeout) ; 
SER disablelnterrupt ( HOST ) ; 

) 

static void 

BADCHECK_robot_proc (uchar src, uchar val) 
{ 

SER enable Interrupt (HOST) ; 
MST cancel (timer ID) ; 

if (src == ROBOT && val == NAK) 

{ 

SECSMSG ack O ; /* indicate ACK to SECS message processing */ 
SER put f HOST. ACK); 
IDLE enter (): 

) 

else 
( 

passThrouo h (src . val) ; 
UNKNOWN enter () ; 

> 

} 

static void 

BADCHECK^robo t_t imeou t (uchar id) 
( 

if (timerlD == id) 
IDkE_enXejr(); 

) 

static void 
ENQ_host_enter ( ) 
( 

state = ENQ__host; 

timerlD = MST create (T2js, ENQ_hos t_t imeou t) ; 
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) 

static void 

ENQ_host_proc( uchar src, uchar val) 
( 

pa ssThrough (src, val ) ; 

if (src == HOST) 
( 

if (val == EOT) 
( 

MST cancel (timer ID) ; 
EOT robot enter ( ) ; 

) 

else 

/* wait for another character from robot 

} 

else 
( 

MST cancel (timerlD) ; 
UNKNOWN enter () ; 

) 

> 

static void 

ENQ_hos t_t imeou t ( uchar id ) 
{ 

if (timer ID == id) 
IDLE enter () ; 

) 

static void 
EOT_robot_enter ( ) 
{ 

state = EOT_robot; 

timer ID = MST create (T2_ms , EOT_robot_timeout) ; 

) 

static void 

EOT_robot__proc (uchar src, uchar val) 
( 

passThrough (src, val) ; 
MST cancel (timer ID) ; 

if (src == ROBOT && 10 <= val && val <= 254) 
MSG host enter (val) ; 

else 

UNKNOWN enter (): 

) 

static void 

EOT_robot„t imeou t (uchar id) 
( 

if (timerlD == id) 
IDLE enter ( ) ; 

) 

static void 

MSG_host_enter (uchar len) 
( 

state = MSG_host; 

char Remain = len ♦ 2; /• include checksum */ 
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timerlD = MST create (Tl_ms , M^G^qs^timeout) ; 

SECSMSG_init () ; /* start saving message for SETS processing */ 

} 

static void 

MSG_host_proc (uchar src, uchar val) 
{ 

uchar dum; 

pa s s Through ( s r c . val); 
MST cancel ( timer ID) ; 

if (src == ROBOT) 
{ 

— char Remain; 

SECSMSG proc (val, charRemain, &dum) ; /* store, process SECS message 
if (charRemain 0) 

CHECK host enter t) ; 

else 

timerlD = MST create (Tl_ms, MSG host timeout ) ; 

) 

else 

UNKNOWN enter () ; 

) 

static void 

MSG_host_timeout (uchar id) 
( 

if (timerlD == id) 
IDLE enter ( ) ; 

) 

static void \^ 

CHECK_host_enter ( ) 

{ 

state = CHECK^host; 

timerlD * MST create (T2__ms, CHECK_host_tiraeout) ; 

) 

static void 

CHECK w host_proc (uchar src, uchar val) 
( 

passThrouoh (src. val); 
MST cancel (timerlD) ; 

if (src == HOST && (val == ACK | | val == NAK) ) 
( 

if (val « ACK) 

SECSMSG ack () i /* indicate ACK to SECS message processing V 
IDLE- ertter O; 

} 

else 

) 

static void 

CHECK_host timeout (uchar id) 
{ 

if (timerlD == id) 
IDLE_enter ( ) ; 

> 

static void 
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IDENQ_host_enter ( ) 
( 

if (msgPtr == NULL I | tryCount++ > MaxRetry) 
{ 

msgPtr = NULL; 
IDLE enter ( > ; 

} 

state = IDENQ_host; 
SER out (HOST. ENQ); 

timerlD = MST create (T2_ms , IDENO host timeout); 
SER disablelnterrupt (ROBOT) ; 

} 

static void 

IDENQ_Jiost_proc (uchar src, uchar val) 
( 

if (src «■ HOST) 
{ 

if (val == EOT) 
{ 

MST cancel (timer ID) ; 
IDMSG host enter () ; 

) 

else 

/* wait for another character from robot 

) 

} 

static void 

IDENQ_host_ timeout (uchar id) 
( 

if (timerlD — id) 
( 

SER enablelnterrupt (ROBOT) ; 
IDENO host enter O; 

) 

) 

static void 
IDMSG^ho s t_ent er ( ) 
{ 

unsigned short checksum a 0; 

state = XDMSG_host; 

SERjput CHOST, msgLen); 

charRemain « msgLen; 
while (charRemain — 1= 0) 
( 

checksum += *msgPtr; 
SERjut ( HOST , *rasgP tr++ ) ; 

) 

SER put (HOST, (checksum & OxffOO) » 8); 
SER put (HOST, (checksum & OxOOff)); 

timerlD = MST create (T2^ms, TDMSG host timeout); 

) 

static void 

IDMSG_host_proc (uchar src, uchar val) 
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{ 

if (src == HOST) 
( 

M5T cancel ( timer ID) ; 

SER enablelnterrupt ( ROBOT) ; 

if (val == ACK) 
( 

msgPtr = NULL; 
IDLE enter () ; 

) 

else 

IDENO host enter (); 

) 

} 

static void 

IDMSG_host„timeout (uchar id) 
{ 

if (timer ID == id) 
{ 

SER enablelnterrupt f ROBOT) ; 
IDENO h o st enter ( ) ; 

) 

> 

static void 
SECSMSG_ini t (void) 
{ 

buf Index = 0; 

) 

static void 

SECSMSG_proc ( uchar inChar, uchar remain, uchar # abortFlag) 
( 

if (buf Index < BUF_SIZE> 

buf (bu£lndex++J = inChar; 

if (remain == 0) 
( 

if ((buf (2] & 0x7f) 3 && buf (31 1) /* S3F1 */ 
S3 Fl_proc( buf Index, buf, abortFlag) ; 

) 

) 

static void 
SECSMSG_ack ( void ) 
{ 

if ((buf (21 6 0x7f) 3 && buf (31 »« 1) /* S3F1 */ 

S3Fl_complete ( ) ; 

) 



-32- 



WO 99/31713 



PCMB98/02147 



S3F1 Message Processing 



S3F1 Message Processing 

Processing an S3F1 message consists of validating the request, aborting the SECS message being 
transmitted to the robot, saving information from the incoming SECS request, initiating an ID system 
read, and formatting the SECS reply when the read completes. The three routines that do this arc, in 
order 

S3F1 proc 

Validates the request (mainly checks the checksum) and, if it's OK, it aborts the SECS message 
being transmitted to the robot by calling SECS abortMsgToRobot and stores away the device 
ID and system bytes from the incoming message. These are stored in the reply messa ge buffer 
where they will be used in the reply. Note that the message must be checked and the message 
aborted before the second checksum byte is sent to the robot - see the discussion in the SECS 
communication control . 
S3F1 complete 

This routine initiates the ID system read . It is done here, and not in S3F1 proc. because if the 
robot fails to respond, we want to propogate a NAK to the host and not initiate a read. Starting 
it here just makes it easier to keep track of what is going on. 
callback 

This routine formats the reply from the ID system. The re ply message buffer is largely Pre- 
formatted, since, except for the data itself, it does not change from read to read. A read error is 
indicated by returning a zero-length list of materials. A reader failure results in an S3F0 (Abort) 
reply. 



S3FLh 

/* 

S3F1 message handling 
•/ 

♦ifndef _S3F1_R_ 
♦define _S3F1_H_ 

extern void S3F1 proc (unsigned char length, unsigned char *msgPtr. unsigned char *a 
extern void S3F1 complete d void) ; 

#endif /* _S3F1_H_ V 



S3F1.C 



•include "exec.h* 

♦include *SECS.h- 

♦include "IDSys.h" 

♦include "S3Fl.h* 



/* forward declarations */ 

static void callback (uchar status, uchar dataLength. uchar *dataPtr) , 
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/* SECS format codes */ 
t define LIST (000 « 2) 
•define BINARY (0X0 << 2) 
♦define UINT1 (051 << 2) 

•define FUNCTION_LOC 3 
•define SECS_HEADER_LENGTH 10 
•define LI ST_L ENGTH_LOC 11 
•define ERR_MSG_SIZE 12 
•define DATA_LENGTH_LOC 26 
•define DATA_LOC 27 



•define MAX_DATA_LENGTH 



8 



/* index of stream byte in SECS header */ 

/* index of error zero- length byte */ 
/* length of error message */■ 
/• index of data length byte */ 
/* index of first data byte */ 
/* max number of data bytes */ 



•define BUF_SIZE (DATA_LOC + MAX_DATA_LENGTH ) 

static uchar buf [BUF__SIZEI « /* pre-loaded with S3F2 format */ 



1* 



0, 0, 
3, 2, 
0x80, i, 
0, 0, 0, 0, 
LIST | 1. 2 
BINARY | 1, 
2, 

LIST | 1, 1. 
LIST | 1, 3, 
BINARY | 1, 1. 

6# 

UINTl | 1, 1, 
1* 

BINARY | 1, 8. 
0 



/* DevID */ 
/* Stream/ Function */ 
/* Block count V 
/* System bytes */ 
/* L, 2 V 

/* <MF> Material format code, 1 byte 

/* 2 => cassette */ 
/* L, m m = I cassettes = 1 */ 
/* L, 3 */ 

/* <LOC> Location code, 1 byte */ 

/* 0 — our own location code? */ 

/* <QUA> Quantitiy in loc. 1 byte */ 
/* 1 — always 1 cassette */ 

/* <MID> Material ID, 8 bytes V 

/* start of data */ 



); 



void 

S3 Fl_proc (uchar length, uchar *msgPtr, 
( 

uchar i; 

unsigned short checksum; 



uchar *abortFlag) 



♦abortFlag = FALSE; 

if ( length = SECS_HEADER_LENGTH ♦ 2 /* including checksum */ 

&& (msgPtrlOJ & 0x80) «- 0) /* R-bit 0 => msg to robot */ 

( 

checksum = 0; 

for (i » 0; i < SECS_HEADER_LENGTH ; i>+) 
checksum ♦= msgPtr [i] ; 



if ( (checksum & OxffOO) » 8 
| | (checksum & OxOOff ) 
return; 



) 



buf (0] = msgPtr (0] 

buf (11 = msgPtrCl] 

buf(6] = msgPtr(6] 

buf (71 = msgPtr(7] 

buf(81 = msgPtr(8) 

buf(9J = msgPtr(91 

♦abortFlag - TRUE; 



0x80; 



msgPtr ( SECS_HEADER_LENGTH 1 
ms gP tr ( SECS_HEADER W LENGTH ♦ 1] > 

/♦ copy DevID; set R-bit */ 
/* copy system bytes */ 



/* cause SECS comm control to abort message being sen 



) 

void 



-34- 



WO 99/31713 



PCT/IB98/02147 



S3F1 Message Processing 



S3 Fl_comp 1 e C e { void ) 
( 

ID_ read (callback) ; 

) 

static void 

callback (uchar status, uchar dataLength, uchar *dataPtr) 
( 

uchar i; 
uchar msgLen; 

switch (status) 
{ 

case SUCCESS: 

buf [FUNCTION_LOC] = 2; 
buf (LIST_LENGTH_LOC) = 2; 

if (dataLength > MAX_DATA_LENGTH ) 
dataLength = MAX W _DATA_LENGTH ; 

buf ( DATA_LENGTH_LOC ) = dataLength; 
for (i » 0; i < dataLength? i++) 

buf ( DATA_LOC + i) = dataPtr(i); 

msgLen = DATA_LOC + dataLength; 
break; 

case READ_FAILED : 

buf [FONCTION^LOC] = 2; 

buf (LIST.LENGTH_.LOCJ =0; /* Zero-length list => no read */ 

msgLen = ERR_MSG_S I Z E ; 

break; 

case READER_F AILED: 
default: 

buf [FUNCTI0N_L0C] = 0; /♦ S3F0 => reader failed */ 

msgLen = S£CS_HEADER_LENGTH ; 

) 

SECS s endMscrToHos t ( msgLen , buf) ; 

) 
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Communication Control for ASCII Interface 

The module is responsible for the coordination of all communication with external devices — the 
host, the robot, the ID system - for the ASCII message protocol configuration. 



Ascn.h 

/* 

Communication control for ASCII interface 
•/ 

#ifndef _ASCII_H_ 
#def ine _ J ASCII_H_ 

extern void ASCII, init (void) ; 

#endif /* _ASCII_H_ */ 



ASCH.C 

♦include <stdio.h> 
♦include <string.h> 

ff include *exec.h* 

♦include *wd.h" 

♦include •msTiroer.h" 

♦include 'serialPorts -h* 

♦include "IDSys-h" 

♦include ' ASCII, h" 

♦define READ.. COMMAND - READID" 

/* Convenient ASCII definitions */ 
♦define CR OxOd 
♦define LF OxOa 
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/* forward declarations */ 

static void receiveHost (uchar inChar) ; 

static void callback ( 

unsigned char status, 

unsigned char dataLength, 

unsigned char *dataPtr) ; 
static void s endRobo t ( uchar dum) ; 
static void receiveRobot (uchar inChar); 
static void sendHostMsa (unsigned char length); 
static void sendHost (uchar dum) ; 
static void timeout (uchar dum) ; 

/* globals */ 

enum 

{ 

RECEIVING_FROH_HOST , 
SENDING_TO_.ro BOT * 
RECEIVING_FR0M_R0B0T . 
SENDING_.T0_.H0ST , 
READING_ID 

static uchar state; 

#define BUF_SI2E 1000 

static xdata uchar buf[BUF_SIZE + 1]; 

static uchar buf Index; 
static uchar charRemain; 

void 

ASCII_init (void) 
{ 

SER setHandler (HOST, RECEIVE, receiveHost); ^ 

SER^setHandler (HOST, SEND, s_endHpst) ; 

SER setHandler (ROBOT, RECEIVE, receiyeRobpC) ; 

SER setHandler (ROBOT, SEND, s_indRpboc) ; 

state = RECEIVING_FR0M_H0ST ; 
buf Index = 0; 

timeout ( 0 ) ; 

) 

static void 

receiveHost (uchar inChar) 
( 

if (state !*= RECEIVING__FR0H_H0ST ) 
return; 

buf [buf Index] = inChar; 

if (buflndex < BUF.SIZE) 
buflndex++; 

if (inChar == LF | | inChar == CR) 

if ( strlen(READ_COMMAND) == buflndex - 1 

&& strncmp( (char *) buf, READ_COMMAND, buflndex - 1) == 0) 

( 

state = READING_ID; 
ID read (callback) ; 

) 

else 



-37- 



WO 99/31713 



PCT/IB98/02147 



Communication Control for ASCII Interface 



< 

state = SENDING_TO_ROBOT; 
charRemain = bu f Index ; 
buf Index = 0; 
sendRobot (0) ; 

} 

) 

) 

static void 
callback ( 

unsigned char status, 

unsigned char dataLength, 

unsigned char *dataPtr) 

{ 

int i; 

if (state != READING^ ID) 
return; 

if (status == SUCCESS) 
( 

sprintf ( (char *) buf, "LPT> %d " , status); 
for (i = 0; i < dataLength; i++) 

( sprintf ((char *) &buf (strlen( (char *) buf)], "%d - ( dataPtrfi]); 
) 

sprintf ((char *) &buf (strlen< (char *) buf) J , "LPT>\n"); 

) 

else 

sprintf ( (char *) buf # "LPT> %d LPT>\n" , status); 

V- 

s endHostMsg (strlen ( (char *) buf)); 

) 

static void 
sendRobot (uchar dum) 
{ 

if (state != SENDING_TO_ROBOT ) 
return; 

if (charRemain — > 0) 
{ 

SER put (ROBOT, buf [buf Index++J ) ; 

) 

else 
{ 

state = RECEIVTNG_FROM_ROBOT ; 
buf Index 3 0; 

) 

) 

static void 

receiveRobot (uchar inChar) 
{ 

if (state != RECEIVING__FROM_ROBOT) 
return; 

buf [buf Index) = inChar; 

if (buflndex < BUF_SIZE) 
buf Index ++ ; 
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if (inChar == LF | | inChar == CR) 
( 

state = RECEIVING_FR0M__R080T; 
sendHos tMsq (buf Index) ; 

) 

) 

static void 

sendHoatMsg (unsigned char length) 
( 

State = SENDING__TO_HOST ; 
..char Remain = length; 
buf Index = 0; 
sendHost (0) ; 

) 

static void 
sendHost (uchar dum) 
( 

if (state SENDING_TO_H0ST) 
return; 

if (charReznain — > 0) 
{ 

SER put (HOST, buf £buflndex++] ) ; 

) 

else 
( 

WD reset ( ) ; 

State - RECEIVING_FROM_H0ST; 
buf Index = 0; 

) 

) 

static void 
timeout (uchar dum) 
{ 

if (state == RECEIVING_FR0M_HOST && buf Index 0) 
WD reset f) ; 

MST create (10000 . timeout) ; 

> 



-39- 



WO 99/31713 



PCT/IB98/02147 



RF ID Interface 



RF ID Interface 

This module initiates an RF system operation to read the transponder in the SMIF pod currently 
placed on the robot, and it delivers the data it reads to a callback routine. The only service it exports 
to the rest of the IMM is ID rend , and the only parameter ID.read takes is the callback routine. The 
status of the call, length of data, and a pointer to the data read are passed to the callback. The THUS 
system responds with an error message if the read fails for some reason (no transponder, multiple 
transponders, corrupted message, etc.), so the status differentiates between a failed read attempt (error 
message) and the reader failing (no response). The eight data bytes are sent to the callback routine 
least significant byte first. 

Internally, the module goes ,;gh a very simple sequence of states : it is IDLE, an ID_read call 
makes it busy SENDING„CO:. iMAND, after completing the send it waits while 
RECH1VTNG_REPLY, and J:nr receiving the reply (or timing out, if the reader should fail) and 
sending the data to the callback ; outine, it becomes IDLE again. The read command is just a pre- 
loaded five-byte array of characters stored in rcadCmd . The response is stored in readRcp ly. The 
receiving routine checks the IcngLh, status, and BCC (longitudinal redundancy check byte, the Xor of 
all the bytes in the message excluding the start mark) in the response. The format of the TIRIS 
messages are documented in ihc TIRIS micro-reader reference manual, available from Texas 
Instruments. 



IDSys.h 

/* V. 
ID system interface 

Reads from RFID sysc r.. invokes callback on completion 
*/ 

#ifndef _IDSYS_H_ 
#define _IDSYS_H_ 

/* Read status */ 

{ 

SUCCESS , 
READ_F AILED, 
READEBL.FAILED 

); 

typedef void (*ID_calIback) < 
unsigned char status, 
unsigned char dataLen-ch, 
unsigned char *dataPtr) ; 

extern unsigned char ID read f ID callback cb) ; 

#endif /* _IDSYS_H_ */ 



IDSys.c 
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#include -reg80c32O.h" 
# include " exec . h " 
#include •IDPort.h" 
# include 'msTimer.h' 

# include "IDSys.h* 

/* ID reader timeout, milliseconds */ 
•define IDJTIMEOUT 200 

/* Convenient ASCII definitions */ 
♦define SOH 0x01 

/* forward declarations */ 
static void sendID (uchar dum) ; 
static void receivelD (uchar inChar) ; 
static void reply (uchar status) ; 
static void timeout (uchar timer ID) ; 

/* globals */ 

enuxn /* allowed states */ 

{ 

IDLE, 

SENDING_ COMMAND , 
RECEIVING_REPLY 

); 

static uchar state = IDLE; 

static uchar char Remain; 
static uchar buf Index; 

static uchar readCmdf] = ( SOH, 0x02, 0x08* 0x32, 0x38 ); 

static uchar timerlD; 

static ID_callback callback; 

•define SUCCESS_REPLY__LEN 12 

•define READ_REPLY_LEN SUCCESS_REPLY_LEN 

static uchar readReply{READ_REPLY_LENl ; 

unsigned char 
ID w read(ID__callback cb) 
{ 

if (state != IDLE) 

return FALSE; /* already busy */ 

if (cb NULL) 

return FALSE; /* need to do something with result */ 

ID setReceiveHandler (receivelD) ; 
ID_setSendHandler (sendID) ; 

state » SENDING_COMMAND; 

timer ID = MST create (ID_TIMEOUT, timeout); 
buf Index = 0; 

charRemain = sizeof (readCrod) / sizeof (readCxad(O) ) ; 
callback = cb; 
sendlD (O) ; 

return TRUE; 

) 

static void 
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sendID<uchar duin) 
( 

if (state != S END ING_COMMAND ) 
return; 

if (charRemain — > 0) 
( 

ID put (readCmd[bufIndex++) ) ; 

} 

else 
{ 

state = RECEIVING.. REPLY ; 
buf Index = 0; 
charRemain = 2; 

) 



static void 

receiveID(uchar inChar) 
( 

if (state J= RECEIVTNG_REPLY) 
return; 

/* first character MUST be an SOH start mark */ 
if (buf Index == 0 && inChar ! = SOH) 
return; 

if (buflndex < READ_REPLY_LEN) 

readReply (buf Index] = inChar; 

bu f Index* +; 

if (buflndex ss 2) /* just read header */ , ■ 

{ v- 
charRemain = readReply [1] +1; /* include BCC */ 

} 

else if ( — charRemain ==0) /* finished message */ 
{ 

state = IDLE; 

MST cancel (timerlD) ; 

if (buflndex == SUCCESS_REPLY_LEN ) 
{ 

uchar i, bcc; 

/* Check status */ 
if (readReply [2] !» OxOC) 
reply ( READER^FAILED ) ; 

. /* check BCC — X*OR bytes of message (skip start mark) */ 
bcc =0; 

for (i » 1; i < SUCCESS_REPLY_LEN - 1; i++) 
bcc ~= readReply [ i) ; 

if (bcc « readReply [ SUCCESS_REPLY_LEN - 13) 
reply (SUCCESS) ; 

else 

repJlY(READER_FAILED) ; 

) 

else 
( 

rep_ly ( R£AD_F AILED ) ; 

) 
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) 

) 

static void 

reply (uchar status) 

( 

if (status »= SUCCESS) 

callback { SUCCESS , 8 , fcreadReply [ 3 ] ) ; 

else 

callback { status, 0, NULL) ; 
callback = NULL; 

> 

static void 
timeout (uchar dum) 
( 

state s* IDLE; 

reply ( READER_FAILED ) ; 

} 
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ID Port Handler 

The ID port handler is configured very similarly to the serial port handlers, except that running the 
external DUART connection are somewhat different from running the internal serial ports. The ID 
port handler services interrupts from the external DUART and invokes a callback routine, if needed; 
and it sends a character to the DUART. The services are the same, without the interrupt 
enable/disable capability: 

ID init 

Initializes the ID port handler, which handles interrupts from EXT4, which is connected to the 
DUART. The DUART has its own crystal, so no internal timer is used. Its registers are mapp ed 
to memory locations in external data. 
ED put 

Initiates sending a character to the ID port, but does not wait for completion. If the port is 
currently busy sending a character, it spin waits for the transmission to complete, though this 
does not normally occur in the current system- 
ID setSendHandler. ID setReceiveHandler 

Sets the ID port SEND and RECEIVE event interrupt handlers. 



BDPorth 

/* 

Initializes, handles interrupts for 

external DUART port 0 (on ext4, interrupt 10) 

V 

#ifndef _IDPORT _H_ 
tdefine _IDPORT_H_ 

extern void IP init (void) : 

extern void ID setSendHandler ( 

void (^handler) (unsigned char dura) ) ; /* NULL => ignore interrupt */ 
extern void IQ setReceiveHandler ( 

void (^handler) (unsigned char value)); /* NULL => ignore interrupt */ 

extern void IP put (unsigned char value) ; 
tendif /* _H)PORT_H_ ♦/ 



roPortc 
/• 

ID port handler 
*/ 

9 include "reg80c320.h* 
A include " exec . h * 

•include -IDPort.h* 
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/* 

DUART register definitions -- National PC16552D 
*/ 

ftdefine ID_BASE(n) 0xF800 + n • 0x100 xdata 



at 


ID_JBASE(0) 


uchar 


RBR 


/* 


read only. DLAB = 0 */ 


at 


ID_BASE<0) 


uchar 


THR 


/* 


write only* DLAB s 0 */ 


at 


XDJBASE(l) 


uchar 


IER 


/* 


DLAB = 0 */ 


at 


ID_BASE ( 2 ) 


uchar 


IIR 


/* 


read only */ 


at 


ID_BASE(2) 


uchar 


FCR 


/* 


write only */ 


at 


ID_HASE(3) 


uchar 


LCR, 






at 


IDJBASE(4> 


uchar 


MCR 






at 


ID_BASE(5) 


uchar 


LSR; 




at 


ID_BASE(7) 


uchar 


SCR, 


/* 


scratch reg, for debugging 


at 


ID_BASE(0) 


uchar 


DLL, 


/* 


DLAB = 1 */ 


at 


ID_3ASE(1) 


uchar 


DLM, 


/* 


DLAB = 1 */ 


/* 


Interrupt handlers */ 





static void ( *sendHandler) (uchar dum) ; 
static void (*receiveHandler) (uchar value); 



/* Software output busy flag */ 
static bool outBusy; 

/* forward declarations V 

static void null_handler (unsigned char dum); 
void 

ID_init(void) 
( 

outBusy - FALSE; 



ID_setSendHandler (NULL) ; 
ID — s e tRece iveHandl er ( NULL ) ; 

/* Set up IDSYS interface to DUART on external int 4 */ 
LCR = 0x80; /* DLAB = 1 */ 

DLM = 0; /* 9600 baud, 18.432 MHz crystal */ 

DLL « 120; 



LCR = 


0x03; 


/* 


DLAB = 0; 8-N-l V 


FCR = 


0; 


/* 


disable FIFOs */ 


IER » 


0x03 ; 


/* 


enable data avail, xmit done interrupts */ 


MCR * 


0; 


/* 


clear modem control, just in case */ 


EXIF &s -0x40; 


/* 


clear interrupt 4 flag, in case it's set */ 


EX4 => 


1; 


/* 


enable external interrupt 4 */ 



static void 

nulljhandler (unsigned char dum) 
{ 

return; /» do-nothing handler, convenient default V 

) 



static void 

handle_IDSYS (void) interrupt 10 
( 

uchar src; 
uchar inChar; 
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EXIF &= -0x40; /* clear interrupt */ 

src - IIR; 

switch (src) 
( 

case 1: 

break; /* no interrupt (??), do nothing */ 

case 2: 

outBusy = FALSE; 
(sendHandler) (0); 
break; 

case 4: 

inChar = RBR; /* read character from DUART register */ 

( r eceiveHandl er ) { inChar ) ; 

break; 

default: 

panic ( UNKNO WN_ INTERRU PT ) ; 

}; 

) 

void 

JD_setSendHandler(void (*new_jhandler) (uchar dum) ) 
{ 

if (new_handler == NOLL) 

sendHandler = null.handler; 

else 

sendHandler = new_handler; 

) s - 

void 

H)_setReceiveHandler<void (*new__handler) (uchar value)) 
{ 

if (new_handler NULL) 

r eceiveHandl er = null__handler ; 

else 

receiveHandler = new_handler; 

) 

void 

IELput (uchar outChar) 
{ 

if (outBusy) 
( 

while (LSR & 0x20 ==0) /* wait for last send to complete */ 
continue ; 

) 

outBusy = TRUE; 
THR = outChar; 

} 
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Serial Port Handlers 

The serial port interrupt handlers perform two basic functions: they set up and service built-in serial 
port interrupts, invoking application callback routines, if needed; and they send characters out the 
serial ports. The services offered to the rest of the system include: 

SER init 

Initializes the serial port handlers and timer 1, which is used to generate the baud rate. Tinier 1 is 
set to run in mode 2 t 8-bit auto-reload mode, at 9600 baud (on a 33 MHz machine). Send and 
receive interrupts are enabled for both PORTO and PORT1, output channels are marked idle, 
and a dummy callback is registered for both SEND and RECEIVE events. 
SER put 

Initiates sending a character on the specified port, but does not wait for completion. If the port 
is currendy busy sending a character, it spin waits for the transmission to complete. SER_put 
determines that output is currently in progress by inspecting the outBusy flag for that channel. 
This flag is set by SER_put, and cleared by the interrupt service routine. 

No buffering or queueing service is. provided by SER_puL This means that if it is called from 
an interrupt service routine, no interrupts will be serviced during the call, which could take as 
long as a millisecond (one character at 9600 baud). This has several consequences in the 
current IMM system. For one, it means that the robot and host interfaces should be operated at 
the same baud rate, since otherwise one could overrun the other in the absence of speed 
matching buffering. For another, it means that if a routine has more* than one character to send, 
it must either supply its own output interrupt service routine (as ID System does), or be used in 
such a situation that missing other interrupts can be tolerated (as is the case when the SECS 
communication controller sends an IMM message to the host). 

SER setHandler 

Associates a callback routine with a particular port and event (SEND or RECEIVE). If the 
callback routine is NULL, then a do-nothing dummy callback routine is registered. 
SER enablelnterrupt. SER disablelnterrupt 

Enable/disable interrupts on the indicated port These routines arc used by the SECS 
communication control to shut down and restore communication with the robot during IMM- 
host conversations. 

The actual interrupt handlers, handle portO and handle portL do little more than reset the hardware 
and software flags associated with the port, and invoke the registered callback routine. Note the 
peculiar interface to the portl handler this is a result of working around a problem with the Franklin 
DS80C320 simulator handling of portl interrupts. See the workaround discussion in the main exec 
routine for more detail. 



serialPorts.h 

/* 

Initializes, handles interrupts for 
internal serial port 0 (interrupt 4) 
internal serial port 1 (interrupt 7) 

The serial port driver " owns • timer 1 ( interrupt 3 ) , 
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which is used to generate the baud rate 
•/ 

♦ifndef _SERIALPORTS_H_ 
#de£ine _S ERIALPORTS_H_ 

/* assign ROBOT, HOST to PORTS */ 
♦define ROBOT PORTO 
♦define HOST PORT1 

/* port identifiers */ 

enuin 

( 

PORTO = 0, 

PORT1, 

NOM_PORTS 

}; 

/* events */ 

enum 

.{ 

SEND = 0 , 

RECEIVE, 

NUM_EVENTS 

); 

extern void SER init (void) ; 

extern void SER enablelnterrupt (unsigned char port); 
extern void SER disablelnterrupt (unsigned char port); 

extern void SER_s etHandler ( 
unsigned char port, 
unsigned char event, 

void (*handler) (unsigned char value)); /* NULL => ignore interrupt */ 
extern void SER put (unsigned char port, unsigned char value); 
frendif /* _SERIALPORTS_H_ V 



serialPorts.c 
/* 

Serial port handlers 
*/ 

♦include ■reg80c32O.h" 
♦include "exec.h" 

♦include "serialPorts .h - 

/* Array of interrupt handlers */ 

typedef void (*t_handler) (unsigned char value) ; 

static t_handler handler (NUM_PORTS) [NUM — EVENTS] ; 

/* Vector of software output busy flags */ 
static boo! outBusy (NUK.PORTS) ; 

/* forward declarations */ 

3tatic void null_handler (unsigned char dum) ; 
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void 

SER^JLnit (void) 
( 

int i, j; 

for (i - 0; i < NUM_PORTS; i++) 
{ 

outBusy(i) = FALSE; 

for (j = 0; j < NUM_EVENTS; 

handler ( i ) [ j 1 = null_handler; 

} 



} 



/* Set up timer 1 to run 9600 baud serial I/O */ 

TMOD = CEMOD & OxOf) | 0x20; /* Timer 1 => mode 2 <8-bit reload) */ 
TH1 = 0xf7; /* Reload value for 33.00 MHz, 9600/19200 baud •/ 
TL1 = 0xf7; /* Make first time-out correct */ 
TR1 « 1; /* Start timer */ 

/* Set up internal serial port 0 */ 

PCON &» -0x80; /* set SMOD for 9600 baud */ 

SCON0 = 0x50; /* mode 1 (vaxi baud) , receive enable */ 

SER enablelrtterrupt ( PORTO ) ; 

/* Set up internal serial port 1 V 

SMOD_l =0; /* set SMOD for 9600 baud */ 

SCON1 a 0x50; /* mode 1 (vari baud) , receive enable */ 

SER enablelnterrupt ( PORT1 ) ; 



void 

SER_enableInterrupt (unsigned char port) 
( 

if (port == PORTO) v ' 
{ 

RI__0 =0; /* clear input interrupt */ 

TI_0 =0; /* clear output interrupt */ 

ES0 =1; /* enable port 0 interrupt */ 

) 

else if (port == PORT1) 
( 

RI_1 =0; /* clear input interrupt */ 
TI_1 =0; /* clear output interrupt */ 
ESI si; /* enable port 1 interrupt */ 

) 

) 

void 

SER^disablelnterrupt (unsigned char port) 
( 

if (port == PORTO) 

ES0 = 0; 
else if (port == PORT1) 

ESI = 0; 

) 

static void 

null_handler (unsigned char dum) 
( 

return; /* do-nothing handler, convenient default */ 

) 



static void 

handle_port0 (void) interrupt 4 
( 
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uchar inChar; 



if <TI_0 == 1) 
{ 

TI_0 = 0; /* clear output interrupt */ 

outBusy ( PORTO ] = FALSE; 
(handler [PORTO) (SEND) ) (0) ; 

) 

if (RI_0 == 1) 
{ 

inChar = SBUFO; /* read character from portO buffer */ 
RZ-O fl 0; /* clear portO receiver interrupt flag */ 

(handler (PORTO) (RECEIVE) ) (inChar) ; 

) 

) 



#ifdef SIM 
void 

handle__portl (void) 
#else 

static void 

handle_portl (void) interrupt 7 

iendif 

{ 

uchar inChar; 



if <TI_1 == 1) 
( 

TI_1 » 0; /* clear output interrupt V 

outBusy (PORTl) = FALSE; 
( handler (PORT1 ] [SEND) ) (0) ; 

) 



if <RI_1 == 1) 
{ 

**_1 * 0; /* clear portl receiver interrupt flag */ 

inChar = SBUF1; /* read character from portl buffer */ 
(handler [PORT1) [RECEIVE) ) (inChar) ; 

) 

void 

SER_setHandler( 

unsigned char port, 

unsigned char direction, 

void (*new_handler) (uchar value) ) 



) 



if (new_handler »a NULL) 

handler [port] [direction) = nu Unhandier; 

else 

handler [port) [direction] = new_handler; 



void 

SER_put (uchar port, uchar outChar) 

switch (port) 
( 

case PORTO : 

if (outBusy ( PORTO ] ) 
{ 

while (TI_0 == 0) 

continue; /* wait for previous output to complete V 
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Tl_o = 0; 

) 

SBUFO = outChar; 
break; 

case PORT1: 

if (outBusy[PORTU ) 
( 

while <TI_1 == 0) 

continue; /* wait for previous output to complete */ 
TI_1 = 0; 

) 

SBUF1 = outChar; 
break; 

default: 

return; 

) 

outBusy[port] = TRUE; 
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Millisecond Timer Handler 

This module implements in software a general-purpose millisecond-level timer facility which allows 
a client to register a routine to be run a designated number of milliseconds in the future. This is used 
to implement timers in the communication protocol, and to provide a safety net should the RF ID 
system fail to respond. It uses the built-in timerO. 

Timers are created by invoking MST create, passing it the delay in milliseconds and a pointer to the 
callback routine. The return value is a timerlD, a value that may be passed to MST cancel to cancel 
the timer. The callback routine takes one argument, the timerlD for which it was invoked, and should 
return no value. (Taking a second argument, such as a byte of user-defined data, was considered, but 
the IMM application did not have any use for it, and it would have increased the size of the timer data 
structure.) 

The basic data structure that the timer routines use simply contains ticksRemain, the number of ticks 
left until the timer expires, and the callback routine address. The timerlD is an index into a statically 
allocated array of these structures. Every time the interrupt handler for timerO is entered, the number 
of ticks remaining in each timer struct is checked, and when it drops to zero the callback routine is 
invoked. MST create just searches the array for an unused entry (if the ticksRemam is zero, the timer 
isn't being used), and MST cancel just sets ticksRemain to zero. The initialization routine, MST fait. 
clears the array and starts up timerO. 

One limitation to the use of millisecond timers arises from the fact that u>e current implementation 
maintains a static array of NUM TIMERS timer data structures in the onihip data area, so there is 
an upper limit on the number of simultaneously available timers. NUMJITMERS is currently set to 
four. 

Another limitation arises from the fact that in the timer data structure the number of ticks left before 
expiration is m a in ta in ed as a two-byte integer. Using a 10 ms. tick (27500 cycles of the 33.00 MHz 
crystal, counted every 12 cycles), this allows a maximum period of 65536 sec. (about 10 min.) with a 
resolution of 10 ms. 

Note that in order to get a reasonably long tick we use timerO in mode 1, 16-bit mode, so we have to 
reload the count manually in the interrupt handler. This behavior is somewhat different from the way 
timerl is used in auto-reload mode to clock the serial ports. 

msTimenh 

/* 

Millisecond software timers 
Uses timerO (interrupt 1) 

This implementation has a maximum wait of 655.36 sec (about 10 min.) 
with a resolution of 10 ms. 

This implementation currently only allows NUM__TIM£RS simultaneous 

timers . 

*/ 
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♦ifndef _MSTIMER_H„ 
* define _JMSTIMER_H_ 

♦define LOG_NUM_TIMERS 2 

♦define NUM_TIMERS (1 « LOG_NUM_T IMERS ) 

♦define INVALID_TIMERID NUM_TIMERS 

extern void MST init (void) : 

extern unsigned char MST create ( 
unsigned long ras , 

void (*callback) (unsigned char timerlD) ) ; 
extern void MST_cancel (unsigned char timerlD); 
♦endif /* _MSTIMER_H_ */ 



msTimer.c 
/* 

Use timer 0 to implement software timers 

27500 cycles of the 33.00 MHz crystal, counted every 12 cycles 
takes 10 ms. 

We use mode 1, the 16-bit timer mode, and reload manually every interrupt. 

Using a two-byte tick count field and a 10 ms tick we get a 
maximum timer value of 655.36 sec, about 10 rain. i - 
V 



♦include *reg80c320.h" 
♦include "exec.h" 

ft include 'msTimer .h" 

•define MS_RESOLUTION 10 

♦define NUM_CYCLES 27500 

# define RELOAD_VALUE 65536 - NUM_CYCI*ES 

♦define RELOAD_HI (RELOAD_VALUE & OxffOO) » 8 

♦define RELOAD_LO RELOAD_VALUE & OxOOff 

static data struct 
{ 

unsigned Short ticksRemain; /* 0 => not in use */ 
uchar timerlD; 

void (^callback) (uchar timerlD); 
) timers (NUM_TIMERSJ ; 

static uchar currTimerBase; 

void 

MST_init(void) 
{ 

uchar i; 

currTimerBase = 0; 

/* clear soft timer data structure */ 
for (i = 0; i < NUM__T IMERS ; i+-»-) 
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I 

timers ( i] . ticksRemain = 0; 
/* set up timerO */ 

TMOD = (TMOD & OxfO) | 0x01; /* Timer 0 => mode 1 (16-bit timer) */ 
THO = RELOAD_HI ; 
TLO = RELO AD_LO ; 

TRO = 1; /* Start timer */ 

ETO =1; /* Enable timerO interrupts */ 

} 

static void 

handleMsTiraer (void) interrupt 1 
< 

int i; 

• THO = RELOAD_HI ; 
TLO = RELOAD_LO ; 
TRO - 1; 

for (i s 0; i < NUM_TIMERS ; i++) 
{ 

if (timers (i) .ticksRemain ! = 0) 
{ 

if ( — timers [i) . ticksRemain == 0) 
{ 

{ timers [i] .callback) ( timers [ij . timer ID) ; 

) 

) 

) 

) 

uchar ^ 
MST_create( 

unsigned long ms. 

void (* call back) (uchar timer ID) ) 

( 

uchar i; 
uchar timerlD; 

ms a (ms < MS_RESOLUTION) ? MS_RESOLUTION : ms; 

for (i = 0; i < NUM_TIMERS; i++) 
{ 

if ( timers (i) .ticksRemain == 0) 
{ 

timer ID = (currTimerBase++ « LOG_NUM_TIMERS) + i; 
timers (il . ticksRemain = (unsigned short) (ms / MS^RESOLUTION) ; 
timers (i) .timer ID = timerlD; 
- timers (i) .callback = callback; 
return timerlD; 

) 

} 

panic (NO MORE TIMERS) ; 

) 

void 

MST_cancel (uchar timerlD) 
{ 

uchar i; 

i a timerlD & (NUM_TIMERS - 1) ; 
if (timers (il .timerlD timerlD) 
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timers Ci ). ticksRemain = 0; 
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Watchdog Timer Handler 

This handler implements a simple watchdog timer, based on the DS80C320's hardware capabilities. 
Ifs purpose is to reset the micro-controller in case it get hung for some reason. "Getting hung** is 
inferred from a lack of change when change is expected. The timer is initialize by the executive 
during initialization, and reset periodically by the communication control finite state machines as 
external events move them through their sequence of state transitions. The timer will accumulate 
MAX TICKS ticks before resetting the CPU. The current values, MAXJTICKS = 128 and 2 A 26 
clocks @ 33 MHz per tick, allow 4-5 minutes to pass without progress before the watchdog goes off. 

Note the use of the TIMED ACCESS macro to set the protected registers associated with the 
watchdog timer. 



wd.h 

Sifndef _WD_H_ 
ftdefine _WD_H_ 

extern void WD Lnit (void) ; 

extern void WD reset (void) ; 

#endif /* _WD_H_ */ 



wd.c 

ftinclude "reg80c320 .h" 
♦include "wd.h" 

/* Number of -2 sec TICKS before reset */ 
•define MAXJTICKS 128 

static unsigned char resetCount; 

void 

WD_init (void) 
( 

resetCounc =0; /* clear software count */ 

CKCON |= OxCO; /* set watchdog interval to 2 A 26 clocks V 
/*' (about 2 sec at 33 MHz) */ 

TIMED_ACCESS<RWT = 1); /* restart (clear) watchdog timer */ 

TIMED_ACCESS(EWT = 1); /* enable reset mode •/ 

TIMED_ACCESS(WDIF « 0); /* clear watchdog interrupt flag */ 
PWDI = 1; /* set watchdog interrupt priority to high */ 

EWDI = 1; /* enable watchdog interrupt */ 

void 

WD_reset (void) 
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( 

resetCount = 0; 

) 

static void 

handle_WatchDog(void) interrupt 12 
{ 

if (resetCounc++ < MAX_TICKS) 
TIMED_ACCESS(RWT =1); 

TIMED_ACCESS (WDIF - 0) ; 
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Executive Routine 

The main routine in the program serves only to initialize the various modules, then enable interrupts 
and enter a do-nothing idle loop (though note the conditionally compiled workaround! 

The panic routine is a simple-minded way of stopping the IMM: it disables interrupts, sets an error 
code at the beginning external data memory, and spins. There might be something better to do — add 
a display to the board to hold the error code? — but I can't think of anything. I have never seen this 
routine called in any phase of our testing. The error codes are defined in execJi. 

There are a couple of conditional compilation parameters defined in the executive. Two of these, 
ASCII and SECS, control whether code for the ASCII or SECS interface is run during initialization. 
The other, SIM , controls the inclusion of code to work around the inability of the Franklin software to 
simulate serial port 1 interrupts. 



exech 

frifndef _EXEC_H_ 
ftdefine _EXEC_H_ 

/• 

Define when compiling Co run on Che Franklin DS80C320 simulator 
Comment out when compiling to run on actual micro-controller 

#define SIM 

V 

typedef unsigned char uchar; 
typedef unsigned char bool; 

ftifndef TRUE 

# define TRUE {0 == 0) 

#define FALSE (! TRUE) 

frendif 

#i£nde£ NULL 
i define NULL 0 
iendif 

/* 

panic codes 
•/ 

tdefine NO_MORE_TIMERS 1 
# define UNKNOWN_ INTERRUPT 2 

extern void panic (unsigned char) ; 

ftendif /♦ _EXEC_H__ */ 



execx 
/* 

Main initialization driver # entered on reset. 
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Add calls to initialization routines after "here -->■ 



/* 

Define appropriate interface type 
#define ASCII 
V 

# define SECS 

♦include "reg80c320 .h* 

# include "wd.h" 
# include 'serialPorts .h a 
# include " msTimer . h * 
♦include • ASCII. IT 
♦include 'SECS.h* 

♦include "exec.h" 



void 

main (void) 
{ 

/* 

Disable interrupts, including external interrupts 

and power fail. Initialization routines enable 

their own interrupts. 

*/ 
IE = 0; 
EIE = 0; 
EPFI =0; 



Call initialization routines here — > 
(Note: order is important!!) 



WD init <) ; 
MST init O ; 
SER init O ; 

♦ifdef ASCII 

ASCII init () j 
♦endif 
♦ifdef SECS 

SECS init O ; 
♦endif 



/* watchdog timer */ 
/* millisecond timer */ 

/* serial ports 0 & 1, external interrupt 4 */ 



/* communication control for ASCII interface */ 
/* communication control for SECS interface */ 



EA 



l; 



/* globally enable interrupts */ 



for (;;) 
{ 



♦ifdef SIM 



This is a workaround for a bug in the Franklin DS80C320 simulator. 
Since the simulator fails to generate interrupts properly for 
serial port 1, we just spin in the idle loop waiting for RI or TI 
to be set, and then we call the handler directly. Note that 
we must also change the declaration of the handler, so it does 
an RET instead of a RETI. This code is not used in production 
(though it's easy to forget to change it). 
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if (RI_1 == 1 || TI_1 == 1) 
( 

EA = 0; 

ha ndle portl ( ) ; 
EA = 1; 

) 

tendif 

continue; /* background task — idle loop */ • 

) 

) 

/* 

Panic routine put-s an error code at start of external data, 
and spins to halt processor 

There must be something better to do. 
*/ 

at 0x0000 xdata uchar HaltCode = 0; 
•void 

panic (uchar errCode) 
{ 

EA = 0; /* turn off interrupts */ 

HaltCode = errCode; /* set error code */ 
halt: 

goto halt; /* spin */ 

) 



This invention has been described and illustrated in connection with certain preferred 
embodiments which are illustrative of the principles of the invention. However, it should be 
understood that various modifications and changes may readily occur to those skilled in the art, and 
it is not intended to limit the invention to the construction and operation of the embodiment shown 
and described herein. Accordingly, additional modifications and equivalents may be considered as 
falling within the scope of the invention as defined by the claims hereinbelow. 
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WHAT IS CLAIMED IS: 

1. A module for use in a system for processing articles, which system includes a 
plurality of machine tools for processing articles, a pod for carrying the articles to be processed by 
said machine tools from one machine tool to another, a host processing controller associated with 
said machine tools for controlling the operation thereof; a robot connected to each said machine tool 
for receiving said pod, opening said pod and for transporting the articles from within said pod into 
position on said machine tool for processing, and an identification means carried by said pod for 
identifying a particular pod and the articles carried therein, said module comprising single wire 
connection between said identification means, said host controller and said robot. 

2. The module according to claim 1 wherein said single wire connection is carried by a 
microprocessor having means for identifying the source of a communication signal for routing said 
communication signals between said identification means and said host controller and between said 
host controller and said robot depending upon its source. 

3. The module according to claim 2 further comprising a reader connected to said 
microprocessor for reading said identification means when said pod is placed on said machine tool 

4. The module according to claim 3 wherein said identification means has an RF 
transmitter and said reader comprises an RF receiver. 
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5. The module according to claim 3 wherein said identification means has an infrared 
transmitter and said reader comprises an infrared receiver. 

6. The module according to claim 3 wherein said identification means is a barcode and 
said reader comprises an optical character reader. 

7. The module according to claim 3 further comprising detecting means mounted on said 
machine tool for detecting the presence of said pod, said detecting means connected with said host 
controller, whereby when said host controller receives a message from said detecting means that a 
pod is in place for processing on said machine tool said host controller will issue a command to said 
reader to identify said pod by reading its identification means. 

8. The module according to claim 7 further comprising a power source and power 
regulation means for providing power to said microprocessor and to said reader. 
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